Internet Warrior 1993 July

home *** CD-ROM | disk | FTP | other *** search

/ Internet Warrior 1993 July / Internet Warrior No. 1 July 1993 - Austin Code Works.ISO / tcpip / slip / sliphelp.txt < prev next >

Wrap

Text File | 1993-04-04 | 46.7 KB | 1,120 lines

The following file is the help file for SLIPDIAL, a BETA product of the University of Minnesota Computing and Information Services. Until its release, we cannot be held accountable for its behavior if you wish to try it out. YOU HAVE BEEN WARNED. Special Notes: Beginning with version 1.00b1 we are employing the X00 device drivers by Raymond Gwinn. Using this product may involve running an installation disk or some simple editing on your part. Please read the section "BEFORE YOU BEGIN:X00" for more information. SLIPDIAL Copyright (C) 1991 University of Minnesota CIS Written by Bob Alberti: comments and questions to slip@boombox.micro.umn.edu. SLIP stands for Serial Line Internet Protocol, and allows a computer to act as a TCP/IP node using a modem over the telephone line. This would make programs such as Popmail, Gopher, Telnet or FTP available for use from home, or anywhere that a LAN connection may not be available. This is accomplished by way of a "packet driver": a program which handles communications between a computer and the network. The SLIP8250 packet driver is written specially for SLIP communications, and uses your serial port instead of a network connection to communicate with the network. In order for this to work, a network must have a "SLIP server", a program which monitors an incoming modem for SLIP connections and translates the modem signals into standard TCP/IP network signals. Additionally, you may have some form of security system (such as TACACS) controlling who can connect to a SLIP server and receive an IP address. CONCEPT Until now, using SLIP was difficult. First you had to call a SLIP modem pool, using a your modem and a communications program such as PROCOMM. Then you would tell the modem pool that you wanted to use SLIP, and receive an IP address to use for the session. Then you would exit the communications program, being careful not to disconnect your modem (by leaving DTR on for you experts), and edit a configuration file, adding your IP address to the configuration. Finally, you would load your packet driver and you could use Telnet or FTP. This was very cumbersome. The SLIPDIAL program is designed to automatically connect to a local SLIP server, configuring your computer and loading the SLIP8250 packet driver. Ideally you can enable the use of such programs as Telnet and FTP simply by using the command: SLIPDIAL and be automagically connected. CONTENTS The Main Program: SLIPDIAL.EXE -- the main program. The Documentation: SLIPDIAL.HLP -- short help file for SLIPDIAL. SLIPHELP.TXT -- this file, long help for SLIPDIAL. CHANGES -- the most recent changes to SLIPDIAL. Scripts: DEFAULT.SLP -- a default SLIPDIAL script. SLIPDIAL uses a simple command language (see SCRIPT COMMANDS below) in order to customize connections to different SLIP servers. If you are not connecting to the University of Minnesota's modem pool, you may need to customize this script. GENERIC.SLP -- initially identical to DEFAULT.SLP, GENERIC.SLP can serve as a template when customizing your SLIPDIAL scripts. Make changes to GENERIC.SLP and test it using the command SLIPDIAL -s generic.slp which is explained further in the COMMAND FORMAT section below. ADI100.SLP -- a specialized SLIPDIAL script for use with the University of Minnesota digitized telephone system. If this is the means by which you will be regularly connecting to SLIP service, then copy this file on top of the DEFAULT.SLP file with this command COPY ADI100.SLP DEFAULT.SLP and you will use this script automatically. HANGUP.SLP -- a script which is used to shut down SLIPDIAL when finished. It is usually invoked by a batch file, but the command to activate it by hand is SLIPDIAL -s HANGUP.SLP Support programs: SLIP8250.COM, PKTCHK.COM and TERMIN.COM, plus other TCP/IP programs included in NCSA Telnet from the University of Illinois, Urbana-Champaigne. This package can accessed by anonymous FTP to zaphod.ncsa.uiuc.edu. You will need to customize CONFIG.TEL to use either BOOTP or an IP address which is received from your SLIP server and inserted into CONFIG.TEL. See the COMMUNICATIONS and BEFORE YOU BEGIN sections below. Communication drivers: X00.SYS was written by Raymond Gwinn and is distributed here with the author's permission. CONFIG.X00 contains a line which must be added to the root-level CONFIG.SYS file. This line references X00.SYS, which in turn must be in the root directory. If you must set this up by hand, here are the commands to execute (assuming that X00.SYS and CONFIG.X00 are in the current directory): COPY X00.SYS \ COPY CONFIG.X00 \ CD \ TYPE CONFIG.X00 >> CONFIG.SYS and then reboot the computer. BEFORE YOU BEGIN X00 The current version (1.00b1 and greater) of SLIPDIAL uses Raymond Gwinn's X00 serial device driver (X00.SYS). The X00.SYS program handles the communications between SLIPDIAL and the modem until SLIPDIAL has finished running, after which it is deactivated. The program X00.SYS is included in the SLIPDIAL.ZIP package, and is automatically set up for you if you used the installation program. However it is possible that you obtained SLIPDIAL by some other means, or that you wish to check to make sure everything is in place, so setup instructions follow. Setting up X00 is easy, simply involving adding a line to your CONFIG.SYS file and making the program available. To CONFIG.SYS, add the line: DEVICE=\X00.SYS E and then make sure the file X00.SYS is located in the root directory of your boot disk. Upon rebooting the computer, the X00.SYS program will automatically be loaded into memory, ready for SLIPDIAL to use. This program should not interfere with any other programs, and is quite small. However, if you wish to remove it, change the line in CONFIG.SYS to read REM DEVICE=\X00.SYS E This will cause the line to be ignored, but make it easy to add X00.SYS back in at a later date. If you are using more than one COM port on your computer (for instance, if you have an internal modem, a serial mouse, and an external 25-pin modem port) you may wish to change the line in config.sys to read DEVICE=\X00.SYS # E Where # equals the number of serial devices available. Refer to Appendix A for more information concerning other command-line options to help you fine- tune your X00 driver. CONFIG.TEL Myip Another item which ought to be in place but which you may wish to check, is the CONFIG.TEL file in the \NCSA directory. This file is used by Telnet or other NCSA programs. This file should come correctly preconfigured for the University of Minnesota. However, if you need to change it, here's what you need to know. The first line to check is the "myip=" line. If BOOTP (see COMMUNICATIONS) IS available for your network, the line myip=BOOTP should appear in this file. If BOOTP is NOT available, the line myip= should appear. In this case, you will need to run SLIPDIAL with the -c parameter (see below). If you are using SLIPDIAL at the University of Minnesota, BOOTP is available. If you are using SLIPDIAL elsewhere, and are unsure as to what to do, assume that BOOTP is NOT available. SLIPDIAL will look for a file named CONFIG.SLP, which should be a copy of CONFIG.TEL with the "myip= " line. Upon encountering the ADDRESS script command (see below), SLIPDIAL will parse out the IP address from the server, and combine CONFIG.SLP with the IP address to produce a CONFIG.TEL file in the current directory. Gateways and Nameservers At the end of the CONFIG.TEL file are two entries which are very important. The first entry is the Nameserver entry. A Nameserver is a computer which changes human-readable computer names like "boombox.micro.umn.edu" into computer-readable numeric names (called IP addresses) such as 134.84.130.95. The only way to get from a name to a number is by asking the Nameserver, but then needs the Nameserver's IP address in advance (to avoid a chicken- and-egg problem). This line provides that information. If you are not accessing your network at the University of Minnesota, you'll need to change this entry to the nameserver for your own network in order for Telnet and FTP to work with SLIP. name=ns.unet.umn.edu; hostip=134.84.84.84 nameserver=1 name=nss.unet.umn.edu; hostip=128.101.101.101 nameserver=2 Notice that there are two lines, because the second is a backup server in case the first should fail. Also, the names listed are meaningless since only the hostip addresses for these entries are used. The second entry is the Gateway, which is the computer that routes your messages out onto the main portion of the network (called the "backbone"). The Gateway should be easy to determine if you first obtain your SLIP address. For whatever address you get, the Gateway should be: SLIP Address: 123.45.67.89 Gateway: 123.45.67.254 And this gateway should then be valid for all SLIP addresses on a given network. For the University of Minnesota this line should read name=dialup-slip-1-0.gw.umn.edu; hostip=134.84.101.254 gateway=1 Again, the name entry is not used. WHAT SLIPDIAL DOES When establishing a SLIP session your computer is always in one of three states: 1) DISCONNECTED: using the modem to make a connection. 2) CONNECTED: registering with the SLIP server. 3) CONFIGURATION: configuring PC and loading SLIP packet driver. In the initial DISCONNECTED state, communications through the serial port go to the modem, and the commands you type are echoed from the modem. Once the program reaches the CONNECTED state, commands are no longer echoed from the modem -- it "passes through" all data, becoming invisible to the communication process. One changes from the DISCONNECTED to the CONNECTED state by using the "CONNECT" command (see SCRIPT COMMANDS). For instance, if one receives the line "CONNECTED" from the modem when carrier is established, the script commands WAITFOR "CONNECT" 5 IF "CONNECT" CONNECT "Connected to server" ELSE "Could not connect" HALT ENDIF tell SLIPDIAL that the program is now in state #2, the CONNECTED state. Note that if the computer does not receive "CONNECT", it will stop running SLIPDIAL after printing the message "Could not connect". Similarly, the ADDRESS <string> command places the program into the CONFIGURATION state. "<string>" is the string surrounding the IP address. For instance, if your SLIP server responds to a successful SLIP request with the string slip Entering SLIP mode. Your IP address is 123.456.78.90, MTU 1524 bytes. then the command ADDRESS Your IP address is *, MTU will match the string surrounding the IP address itself (note that newline characters are represented by \n's as in the 'C' language). The actual address (123.456.78.90) will then be parsed out of the input stream and used for configuration. However, if your SLIP server employs BOOTP configuration, the ADDRESS command may not be needed. In the CONFIGURATION state, SLIPDIAL takes either one or two steps to prepare your computer to use SLIP (see COMMUNICATIONS): Step 1: When the SLIPDIAL enters the CONFIGURATION state, it will determine whether BOOTP is available by checking whether the -c parameter was specified in the SLIPDIAL command (see COMMAND FORMAT below). If -c was NOT specified, then BOOTP is available, and the program proceeds to the next step. If -c was specified, BOOTP is NOT available. SLIPDIAL will open CONFIG.SLP (or whatever file was specified) and will read until the "myip=" line is found. It will then insert the IP address into the file, and copy the whole thing into a new CONFIG.TEL file. This file will be read by the NCSA utility programs in order for them to obtain their IP address. Step 2: SLIPDIAL will load the packet driver (see COMMUNICATIONS) into memory (called "launching" the packet driver). In order for this to be accomplished most efficiently, the SLIPDIAL program must itself be removed from memory. Therfore one can either launch the packet driver with the "QUIT" command (see SCRIPT COMMANDS) when exiting SLIPDIAL, or one may suspend the default launch of the packet driver with the -l option (see COMMAND FORMAT). If automatic launching is disabled, SLIPDIAL will instead print the command that should be typed to launch the packet driver. If the command is used alone, the SLIP8250 packet driver is launched with default parameters of: SLIP8250 0x60 -h SLIP 4 0x3f8 9600 1500 COMMUNICATIONS Regular (non-SLIP) networking is accomplished in a very straightforward manner. Tools such as the Telnet program (TELBIN.EXE) or POPMAIL need to send signals over the TCP/IP network. The signals get from your Telnet program to the network connection on the back of your computer by way of a "packet driver". A packet driver is a small program which remains in memory and accepts data (called "packets") from a Telnet or POPMAIL or some other program and sends it to the network connector on your machine (such as a networking card). Since different companies make different networking cards, there are different packet driver programs for each kind of networking card. Here is a simple diagram of what takes place. Arrows mark the direction of data flow [Keyboard] -> [Telnet <-> [Packet <-> [Network <-> [Network] {Screen} <- or POPMAIL] driver] connection] The packet driver for SLIP differs only slightly -- instead of sending the information to a network connector (like an Ethernet card installed in the machine), it sends the information to the serial port. [Telnet <-> [Packet <-> [Serial <-> [Your <-> [SLIP <-> [Network] or POPMAIL] driver] port ] Modem] Modem] The utility program such as Telnet or POPMAIL does not see any difference: after all, these programs talk only to the packet driver. What utility programs need is their IP address, and they can get it one of two ways. The first, traditional, method is to read the IP address out of the CONFIG.TEL file or other configuration file. This is fine for the normal case of a computer connected permanently to a network, with a static address. Recognizing that this is not always the case, BOOTP addressing was developed. BOOTP allows a program such as Telnet to ask "What is my IP address?", and a BOOTP server program on a central machine can check and respond with the IP address. This dynamic method of IP addressing works well for SLIP, where you can get a different IP address each time you connect. However, in order to use BOOTP your network administrators must have set up a "BOOTP server" to watch the network and respond to any "What is my IP address?" requests it may detect. Depending on whether or not you have a BOOTP server for your network, the CONFIGURATION STATE will involve one or two steps (cf CONFIGURATION STATE). If you do not know, it is usually safe to assume you do NOT have BOOTP. SECURITY If you have access to a SLIP server, it's possible that the service is secured with TACACS (Terminal Access Control and Authority Control System) or a similar service. Most of these work by requesting a username and password after the initial connection is made, before the SLIP service is requested. The username and password can be checked against the password file of a machine where you already have an account. For example, let's suppose your account WWWWWWW is on a machine with TCP/IP name XX.YY.ZZ, and you are at home attempting to employ SLIPDIAL. You dial in to your SLIP server (NOT machine XX.YY.ZZ), and encounter the "Username:" prompt. You would type WWWWWW@XX.YY.ZZ and for the password would give your password on that machine. The TACACS system will check with machine XX.YY.ZZ that your username and password are correct, and allow you to use the SLIP service. Other services (TACACS is by far the most popular) may be a simple pre-registry of validated names, and not requre the '@XX.YY.ZZ' specificiation. (Note that in order for TACACS to check your password on your machine, the system operator for XX.YY.ZZ will have to have installed a piece of TACACS software. If you're not sure whether your machine is running the TACACS client, check with your system operator. She or he can then contact slip@boombox.micro.umn.edu for assistance in obtaining and setting up this fairly simple program.) The 'USER' script command can be used to respond to security requests. The USER command has an optional parameter of your name in the form WWWWWW@XX.YY.ZZ. You can place this information into DEFAULT.SLP so that you needn't retype it every time. If you wish to log in under a different name, the command-line parameter -u will override the script information. When the USER command is encountered in the script, you will be asked for your user name (if this information has not been provided as a parameter), and then for your password. Your password will be blanked as you type to prevent it being read by others. You cannot save your password in the script. Since your password is blanked, you will be asked for it twice: the second entry must match the first, or you will need to try again. This process ensures that you type your password correctly. Otherwise you might go through the entire process of calling and connecting, only to have SLIPDIAL fail on a bad password caused by a simple typo. This needs to take place BEFORE the Username is requested by the TACACS server, and ideally can be one of the first lines of the script. This information is held in memory. The SEND command has four special characters, two of which are the '$' and '%' characters. When the SEND command encounters a '$', it sends the value you entered as your Username (WWWWWW@XX.YY.ZZ). Likewise the '%' sends the password. Thus a typical script listing for a TACACS-secured SLIP session might read like this: USER WWWWWW@XX.YY.ZZ : : WAITFOR "CONNECT" "BUSY" 40 IF "CONNECT" CONNECT "Connected" ELSEIF "BUSY" "Line busy." HALT ELSE "Could not connect." HALT ENDIF SEND < WAITFOR "Username:" 2 IF "Username:" "Username requested" SEND $< WAIT 1 ENDIF IF Password: "Password requested" SEND %< WAIT 1 ENDIF SEND slip< QUIT Note that with this script, there is no ELSE case if Username and Password are not requested. This might be useful if you're not sure whether there is TACACS security or not -- if there is, you'll be able to respond, if not, you'll only send the string "slip" to start the SLIP session. SLIPDISK While SLIPDIAL is a simple utility designed for establishing SLIP connections, it is of limited use without something to run over the SLIP connection once it's established. Therefore, preconfigured versions of the University of Minnesota CIS' "POPMail" and "Gopher", and NCSA's "Telnet" and "FTP" have been assembled into a package called SLIPDISK. SLIPDISK is designed to fit SLIPDIAL, POPMail, Gopher and the NCSA programs all onto one bootable 3.5" 1.44 Meg DOS floppy (with a little room to spare). This disk is useful for portable computers, especially those lacking a hard drive. Additionally, a series of installation disks are available, designed to install the SLIPDISK contents onto a hard drive, using either 3.5" or 5.25" high- or low-density floppies. These products are available for Gopher retrieval (or anonymous FTP) from boombox.micro.umn.edu in the /pub/slipdial directories as follows: /pub/slipdial/slipdial.zip -- SLIPDIAL and supporting programs. /pub/slipdial/slipdisk/slipdisk.zip -- SLIPDISK ready to unzip onto a bootable 3.5" 1.44Meg DOS floppy. /pub/slipdial/install/3.5/high -- contents of these directories /pub/slipdial/install/3.5/low used to build installation disks /pub/slipdial/install/5.25/high for installing SLIPDISK onto /pub/slipdial/install/5.25/low a hard drive. COMMAND FORMAT: SLIPDIAL [-a] [-b #] [-c [file]] [-d] [-i #] [-l] [[-n] #] [-p #] [-s file] -a Do NOT build MYIP.BAT file when reading ADDRESS. -b Set Baud rate: 300 - 38,400.* -c Select config.tel or other config file. Turns off default of BOOTP. Config.tel should be complete except that the line "myip=" should be left blank. SLIPDIAL will edit this file and place the IP address it receives from the server into this file. -d Debug (verbose) mode. Script lines and results are displayed. -i Select alternate interrupt.* -l Turn off "autolaunch" of packet driver, just print command instead. -n Select alternate phone number.* A phone number must be specified in a script or the command line. -p Select alternate COM port.* -s Select alternate script instead of DEFAULT.SLP -u Enter a user name.* * Setting this option from the command line will override any options set within the script itself. EXAMPLES: SLIPDIAL Run SLIPDIAL, using the DEFAULT.SLP script file. And launch the packet driver SLIPDIAL -l -n 69600 Run SLIPDIAL, calling 6-9600, without launching the packet driver. SLIPDIAL 555-1212 Use default values but call this number. SLIPDIAL -d -c Turn on debugging, and turn off BOOTP, use default file CONFIG.SLP instead, this assumes DEFAULT.SLP holds the phone number to call. SLIPDIAL -p 2 -c CONFIG.TST -s TEST.SLP Use COM port 2 turn off BOOTP (automatic configuration), use CONFIG.TST for configuration, and run the TEST.SLP script instead of DEFAULT.SLP. TEST.SLP must contain the phone number to call since it's not given. SCRIPTS Scripts are text files containing a list of simple commands which SLIPDIAL follows in attempting to connect with a remote computer. The commands are explained below, and the file DEFAULT.SLP is provided. This script language allows SLIPDIAL the flexibility to connect to a variety of different SLIP servers. SCRIPT COMMANDS # See the COMMENT command. " See the QUOTE command. < $ When these four characters appear as part of a SEND # & command, see the SEND command below. ADDRESS XX*YY This command prepares SLIPDIAL to determine the IP address returned by the SLIP server. XX corresponds to the string returned by the server after the SLIP request is made, preceding the IP address. * corresponds to the position of the IP address itself. YY corresponds to the string following the IP address. By this method, you can rigorously determine the IP address from practically any stream of text. This stream can include newlines represented as '\n', so that more than one line of text can be matched. For example: slip-server> slip Entering SLIP mode. Your IP address is 123.45.67.89, MTU 1524 bytes. The match-string for this process could be: ADDRESS mode.\nYour IP address is *, MTU If your SLIP server employs BOOTP address resolution, this statement is not necessary. However, it does have the effect of parsing your IP address out of the server response and displaying it on your screen, which can be helpful when debugging the program. BAUD R,P,D,S Set baud rate at communications port. Rate = 300, 1200, 2400, 4800, 9600, 19200, 38400 Parity = EVEN, ODD, or NONE Databits = 7 or 8 Stopbits = 0, 1, or 2 Parameters must be specified in order. Only Rate parameter is required, others are optional. COMMENT (#) If the first nonwhite character on a line is a pound-sign, the rest of that line is ignored. CONNECT Place the program in CONNECTED state. DTR [on|off] Turn DTR on or off, or toggle DTR (Data Test Ready). ELSE See the IF command. ENDIF Ditto. FLUSH Dump (ignore) all unread data received thus far. HALT Stop script execution immedately. If "String 1" Once a token ("String 1", "String 2", etc) has been [commands] matched, the next IF statement will process the set [ELSEIF "String 2"] of commands corresponding to that token. If no [commands] matching string was encountered the WAITFOR will : have timed-out, and the ELSE case will be processed. [ELSEIF "String X"] [commands] In order to be processed, the tokens tested for by [ELSE] the IF and ELSEIF statements must match those in [commands] the WAITFOR commands. Tokens which do not match ENDIF will simply never be processed. Not all tokens matched in a WAITFOR command must be tested for in an IF-ELSEIF-ELSE-ENDIF block -- no error would be generated. Untested matches will be treated as a timeout by the ELSE command. IF commands must eventually be closed by an ENDIF. ELSE and ELSEIF statements are optional. ELSEIF statements must have a token parameter Once a token is matched, the next IF statement will process the set of commands corresponding to the token. If no matching token was received (a timeout), the ELSE case will be processed. WAITFOR-IF statements cannot be nested. Tokens cannot yet include returns or \n's. MESSAGE XXXX Prints a message to the screen like the quote command ("), but only one line. More importantly, this message is logged to the SLIPDIAL.LOG file for debugging purposes. NUMBER #### Hayes-compatible phone number to call. Valid characters in this string are digits, the hyphen (-), comma (,) , and asterisk (*) keys, and the letter "W". PORT #### Select COM port (1 through 4). Ports 3 or 4 not recommended. QUIT [XXXX] End-of-script. Optionally execute XXXX command when program terminates. Useful for executing packet drivers other than the default packet driver or default parameters. QUOTE (") If the first nonwhite character on a line is a double-quote, everything between this and the next double-quote will be printed to the screen. Allows multi-line screen messages. These messages are NOT logged to the SLIPDIAL.LOG file. SEND XXXX Send the string XXXX out the comm port; '<' in the string is translated into a return. '#' is translated to the phone number to call (see Number). '$' is translated to the user name entered with USER. '%' is replaced by the password solicited at runtime by USER. TIMEOUT #### Reset maximum time to wait for a character before quitting. USER XXXXX User name for security screening. Password will be solicited when the program runs. When sending, the user name will be substituted for a '$' symbol in the SEND command, the password will be substituted for the '%' symbol WAIT #### Pause and collect data before progressing. Usually follows a SEND to allow time for a response. WAITFOR "String 1" "String 2"..."String X" ## "String1", etc are arbitrary strings (tokens) which may contain spaces. The WAITFOR command will wait for the any token in its list until ## seconds have passed or a match has been made. WAITFOR will return TRUE as soon as any one of the tokens is matched. WAITFOR will return FALSE if the time specified by the last entry, a number, passes without a match. This command is used in conjunction with the IF command in order to match incoming data. XECUTE XXX Execute the DOS command XXXX immediately, and return to SLIPDIAL. Appendixes A and B are exerpts from the X.00 Users Manual, copyright 1990 by Raymond L. Gwinn and used here by permission. For the full text of this manual and the full X00 package including all utilities and documentation, download the package x00v125.zip from boombox.micro.umn.edu in the /pub/slipdial/x00 directory. APPENDIX A: COMMAND LINE OPTIONS The command line options are included in the command line that invokes X00. In several cases only the first 1 or 2 characters of the option need be entered. In other cases, the entire option name must be spelled out. Unless otherwise stated in the following descriptions, the entire option name must be spelled out. The parameters are given one after another on the same line and in any order. The length of the command line is limited only by DOS. Specifying number of ports If a single decimal number is in the X00 command line, it specifies the number of ports that X00 is to simultaneously support. The default is one port. The maximum value of the number of ports is 4 for non PS/2 systems and 8 for PS/2 systems. If you desire to use more than 4 ports on a non PS/2, each port address must be specified (see mapping port assignments below). Input and output buffers are allocated for each of the ports specified. Examples of usage are: When X00 is loaded as a Device Driver DEVICE=X00.SYS 3 DEVICE=X00.SYS 8 When X00 is loaded as a TSR X00 3 X00 8 B option, Locking Baud, Data, Parity and Stop bits Normally, the application program sets the baud rate and other parameters controlling the serial I/O hardware. Some modems provide better performance when the communications from the computer to modem is constant (Locked). That is, the computer to modem speed is not the same as the modem to modem speed. If this option is used, the modem must support RTS/CTS hardware handshaking and the feature must be enabled on the modem. The B command line option requires 2 parameters and allows an optional third parameter. The option is specified in the form B,PORTn,BAUD RATE,PARITY. You will most likely never want to lock the parity, data and stop bits. Examples of usage are: When X00 is loaded as a Device Driver DEVICE=X00.SYS B,0,2400 B,1,19200 or DEVICE=X00.SYS B,1,19200,8N1 When X00 is loaded as a TSR X00 B,0,2400 B,0,19200 or X00 B,1,19200,8N1 Valid locked baud rates are: 75, 110, 135.5, 150, 300, 600, 1200, 1800, 2000, 2400, 3600, 4800, 7200, 9600, 19200, 28800, 38400, 57600, and 115200. I can think of few conditions where it is necessary to use the optional third parameter of the B command line option. The optional third parameter is made up of 3 characters that specify the locked setting for data bits per character, parity bit and stop bit(s) in that order. The optional third parameter can be made up of any combination of the following first, second and third characters. First Second Third 5 N = None 1 6 E = Even 2 7 O = Odd 8 M = Mark (always 1) S = Space (always 0) The first character specifies the number of data bits per character, the second character specifies the handling of the parity bit and the third character specifies the number of stop bits. When 5 data bits and 2 stop bits (eg 5N2) are specified, the number of stop bits will actually be 1.5. As stated above, locking of the parity etc, is not advisable. Anytime an application program attempts to program the baud rate, parity etc, through X00, the locked values will be substituted. Eliminate Normally, when X00 is loaded a copyright notice is displayed for 5 seconds. Using the eliminate option will disable the 5 second display of the copyright notice. Only the first letter (E) is required to invoke this option. Examples of usage are: When X00 is loaded as a Device Driver: DEVICE=X00.SYS ELIMINATE or DEVICE=X00.SYS E When X00 is loaded as a TSR X00 ELIMINATE or X00 E Defer The Defer option creates problems on most systems. The Defer option should be avoided by most users. X00 must use several of the 80x86 interrupts. Normally, X00 will hook itself into the 80x86 interrupts when it is executed. The Defer option tells X00 to postpone hooking into some interrupts until an XU CAPTURE command is executed. If the defer option is used and a subsequent XU CAPTURE is not issued, X00 may not function correctly. Additionally, the XU CAPTURE must be executed prior to executing a multitasker like DESQview. Only the first 2 letters (DE) need to used to specify this option. Examples of usage are: When X00 is loaded as a Device Driver DEVICE=X00.SYS DEFER or DEVICE=X00.SYS DE When X00 is loaded as a TSR X00 DEFER or X00 DE The default for Defer is off. That is, X00 will by default immediately hook into all necessary 80x86 interrupt vectors. DV The DV command line option is only of interest to those using DESQview. The default for this option is off. When on (DV specified in the command line), X00 will make DESQview Pause calls when it seems that the application program is idle. This may make time available for other tasks to use. Refer to your DESQview manuals for details about the DESQview pause command. If you are using DESQview, try the DV option. If it does not adversely affect your system, leave it enabled (on). Examples of usage are: When X00 is loaded as a Device Driver DEVICE=X00.SYS DV When X00 is loaded as a TSR X00 DV FIFO Only the first letter of the command (F) is required to invoke this option. Some of the serial I/O hardware devices have First In First Out (FIFO) buffers. This command line option is used to specify the number of characters that X00 can load into the FIFO during a single transmit interrupt. In general this number should be set the size of the FIFO minus 1. For example, the popular 16550A has a 16 byte FIFO on both transmit and received data. Thus, if this option is used, I suggest the value of 15 be used for the 16550A. Examples of usage are: When X00 is loaded as a Device Driver DEVICE=X00.SYS FIFO=10 DEVICE=X00.SYS F=15 When X00 is loaded as a TSR X00 FIFO=15 X00 F=8 The size of the receive FIFO is always set to the maximum by X00. NOFIFO This command line option is used to completely disable the use of hardware FIFOs. Examples of usage are: When X00 is loaded as a Device Driver DEVICE=X00.SYS NOFIFO When X00 is loaded as a TSR X00 NOFIFO NOPOST Normally, when X00 is executed, it will alter the COM1 through COM4 hardware port addresses in BIOS RAM to match the addresses being used by X00. By doing so, many DOOR type programs that use INT 14h for their serial I/O will work correctly with X00 installed. This option (NOPOST) instructs X00 to leave the BIOS RAM unchanged. Examples of usage are: When X00 is loaded as a Device Driver DEVICE=X00.SYS NOPOST When X00 is loaded as a TSR X00 NOPOST SLOWCPU This command line option is provided for those using slower PCs and those using software that executes large amounts of code on an interrupt level (such as the timer tick). When SLOWCPU is specified, X00 will make the serial ports the highest priority interrupt. This feature allows (most) 4.77 mhz PCs to receive/transmit at full speed. This option may cause problems in some environments. Most protected mode programs, like DESQview, will not allow the priority of the interrupts to be changed. When X00 is loaded as a Device Driver DEVICE=X00.SYS SLOWCPU When X00 is loaded as a TSR X00 SLOWCPU R, Set Receive Buffer Size The R command line option allows the user to set the size of the receive buffer. The default size of the receive buffer is 512 bytes. The size of the buffer must be a power of 2. Valid buffer sizes are: 256, 512, 1024, 2048, 4096, 8192, 16384 and 32768. If an invalid buffer size is specified, the next lower correct buffer size is used. Many users needlessly set the size of the receive (or transmit) buffer too large. Examples of usage are: When X00 is loaded as a Device Driver DEVICE=X00.SYS R=1024 DEVICE=X00.SYS R=2048 When X00 is loaded as a TSR X00 R=1024 X00 R=2048 T, Set Transmit Buffer Size This option is identical to the R command line option (see above) except it sets the size of the transmit buffer. VP or Master Interrupt Enable VP stands for Vector Port which is not a very good name for the option. Some multiple port serial I/O cards default to only two ports enabled when power is turned on. A specified value must be written to an I/O port to enable the additional serial ports. Simply stated the VP command line option says to write the given value to the given port. Examples of usage are: When X00 is loaded as a Device Driver DEVICE=X00.SYS VP=03FF,80 When X00 is loaded as a TSR X00 VP=3FF,80 Both of the above examples in effect says, write the value 80 (hex) the I/O port at 3FF. Mapping port assignments This is the most complicated command line option for many users. By default, X00 maps up to 8 serial I/O ports (PORTS 0 through 7). X00 will (attempt to) determine the hardware architecture on which it is being executed. If a PS/2 is detected then the default Serial I/O port addresses will be set to match the PS/2 (see Appendix . If X00 detects that the system is not a PS/2 type system, then the default port addresses are as follows: 1 - Standard addresses for COM1 and COM2, 2 - The defacto standard for COM3 and COM4, and nothing for COM5 through COM8 (ports 4 through 7). Port mapping is necessary if your hardware configuration does not match the PS/2 or defacto standard for non PS/2 systems. COM1 and COM2 are the same for the PC, XT, AT and PS/2. However, hardware specifications for COM3 through COM8 became available only when IBM released the PS/2. Many multiple serial port cards are available for pre PS/2 systems that use a defacto standard. The most common assignments that I have seen for COM3 and COM4 are: COM3 at port address 3E8 using IRQ 3. COM4 at port address 2E8 using IRQ 4. Above the fourth port, I have not observed anything resembling a defacto standard. X00 will support almost any serial I/O card. However, in most cases, port mapping is required for anything beyond COM1 and COM2. Mapping port assignments uses two basic forms. They are: PORTn=COMn,IRQn PORTn=HEXADDRESS,IRQn Where: PORTn is the X00 port number and must be 0 through 7. COMn is a standard DOS port and must be COM1 through COM8. IRQn is the IRQ use by the serial port and must be IRQ0 through IRQ15. HEXADDRESS is a hexadecimal I/O port address that addresses the serial I/O device. In both basic forms, the IRQn is optional. X00 defaults all IRQn to IRQ3 except COM1 which defaults to IRQ4. Examples of usage are: When X00 is loaded as a Device Driver DEVICE=X00.SYS 0=COM4 DEVICE=X00.SYS 0=COM4,IRQ5 DEVICE=X00.SYS 0=2E8,IRQ3 DEVICE=X00.SYS 2=2E8 When X00 is loaded as a TSR X00 0=COM4 X00 0=COM4,IRQ5 X00 0=2E8,IRQ3 X00 2=2E8 Un-installing X00 (only when running as TSR, not as device driver) When X00 is installed as a TSR, it can be un-installed by simply executing X00 with no command line parameters. If you wish to be sure that you do not accidently un-install X00, always execute it with a harmless parameter like X00 E. APPENDIX B Multi-Tasking By far, DESQview seems to be the multi-tasking software that X00 is most often used with. At the time of this writing, I personally use DESQview to run a multi line BBS. I believe it is best to load X00 before the multi-tasking program and to load it as a device driver. This enables all windows (tasks) access to X00. Loading X00 first also allows multiple windows to share the same IRQ. If you have loaded X00 prior to DESQview, you need to configure the window for no communications. That is, answer NO to the configuration questions, Uses Serial Ports and Optimize communications. I also suggest that you enable printer management within the window. Enabling printer management allows a remote drop to DOS to work on many systems. The Optimize communications option and the Printer management option are established with the DESQview SETUP program. The Uses serial ports (Y,N,1,2) option is in the "Change a Program" portion of window configuration. In several cases I have gained a significant increase in performance by turning X00 on prior to executing a program. Two notable cases are GATEWAY and DOORWAY. I used XU to turn X00 on. For example, XU PORT:n:ON just before invoking DOORWAY or GATEWAY produced significantly better input and output from the programs. Depending on your environment, an XU PORT:n:OFF may have to be issued after the program terminates. Also note that the n for PORTn is 1 less than the n in GATEn and COMn. The communications windows seem to work better if the ticks for the foreground and background are set relatively low. Most people that I have talked to use 2 ticks for both foreground and background. Only experimentation will determine the best setting for your system. If you do not wish to share an IRQ, you can load X00 as a TSR inside a DESQview window. When loaded inside a DESQview window, X00 is only available to programs in that window. X00 should be configured to support only 1 serial port and you should specifically name the port that X00 will use in the command line. For example use X00 0=COM1, instead of X00 1 or just plain X00. Identifying the specific serial port to be used in the window eliminates the chance that X00 will interfere with another active window. I strongly recommend that you use the 16550A (or later) SIO chip if you are using a multi-tasking system of any kind. Most programs written to use BIOS INT 14h will work directly with X00's enhanced services. You should try turning X00 on using an XU PORT:n:ON command just prior to executing the program. Programs that do not have their own interrupt I/O will most likely give better performance.